IBIS Macromodel Task Group Meeting date: 23 August 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM * Luis Armenta Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad noted that Walter wanted to introduce his new [Pin Mapping] modifications proposal. Arpad noted that this could be done under item #7 of the agenda (New BIRDs from the Editorial Task Group). ------------- Review of ARs: - Ambrish to check for collaborators' feedback on his nearly ready new version of the Backchannel proposal. - Done. The new Lightweight Backchannel proposal was presented last week. - Arpad to forward the new Backchannel proposal to Mike LaBonte for posting. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Bob M.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow Proposal: - Discussion: Fangyi noted that he was still working on putting together a formal BIRD. He said he had discussed the proposal with some IC vendors and forwarded it to them for review. New Lightweight Backchannel Proposal: - Bob M.: [sharing last week's presentation] - We can continue to discuss last week's presentation. - I have nothing new to present at this point. - Arpad: I forwarded the proposal to one of our developers, but I do not have the feedback yet. - Walter: From the discussions or emails, someone wanted to let BCI_ID allow you to provide a relative path. - I think it wouldn't hurt to add a line to the description stating that the basename (BCI_ID) can be a relative path from the current directory, an absolute path, or a simple string used in the current directory. - Arpad: Relative to where? - Walter: Relative to the current working directory. - We have DLL_ID to allow the model to write to a file with a unique name. - We have the concept of the current directory (of the process running the .dll, see DLL_PATH documentation). - It's the EDA tool's job to fill in a value for the BCI_ID. - It ensures that all the .dlls in the channel, typically Tx and Rx, but may also include redrivers, are given the same BCI_ID so they can all access the same files and communicate. - Bob M.: We decided that if the EDA tool doesn't yet support this parameter, then we at least leave a mode for the user to force the value. - Walter: Yes, there are two modes of operation. - 1. The EDA tool supports this BIRD. - 2. The EDA tool doesn't support this BIRD and this parameter. In that case the user can use the .ami file itself to set that same value of BCI_ID to be used by both the Tx and Rx. - This backdoor allows model makers to create and test these models with legacy EDA tools that do not yet support this proposal. - Ambrish: It's not clear to me how this is expected to work. - Bob M.: That string (BCI_ID), which may include a prepended path, represents a valid namespace such that the .dll, operating under a specific protocol, can concatenate additional characters to that string when it's creating a specific message file's name. The specifics of the additional characters/names are protocol specific. - Fangyi: What happens if the Tx's BCI_ID is not the same as the Rx's (on the same channel)? Is that allowed? - Bob M.: No, the Tx would not be able to find the files the Rx wrote (and vice- versa). - Radek/Ambrish: How to handle crosstalk is not clearly defined. - Bob M.: We could modify the text to say that, "...all model instances in EACH channel ..." shall have the same unique BCI_ID. - Fangyi: If the EDA tool doesn't support this BIRD then you can probably only run without crosstalk, right? - Bob M.: Walter had proposed that as a way to use the workaround the BCI_ID could be defined (by the user) in the .ami file as a list. - The user would have to choose one value from the list for each separate channel. - Discussion: Arpad noted that the BCI_ID section should probably incorporate some of the "current directory" language from the DLL_PATH section, since BCI_ID is going to allow absolute or relative paths as part of it. Walter and Bob M. agreed that the language will be clarified. Walter noted that he felt we were down to minor editorial changes, and moved to submit this as a BIRD after Bob M. made the changes discussed in the meeting. Ambrish seconded. No one was opposed. Radek and Ambrish noted that Bob Ross had preferred that this proposal be submitted as a new BIRD rather than a new draft of BIRD 147. Radek noted that he thought Bob Ross' preference stemmed from the fact that the new proposal was so drastically different that the diff between versions would be hard to view. Ambrish and Arpad noted their preference for submitting the new proposal as BIRD 147.1. Mike L. stated that it was really up to the BIRD's author, and that submitting it as a new BIRD would result in competing proposals, one of which would ultimately be voted down. Ambrish moved to submit the new proposal as BIRD 147.1. Walter seconded. No one was opposed. - Mike L.: If you have a channel with redrivers, then there are multiple Tx and Rx .dlls operating with the same BCI_ID. How do they know which is training which if they all use the same BCI_ID? - Discussion: Arpad, Fangyi, and others also questioned how this would work in a redriver case. Walter said it was up to the protocol to decide. He then described a protocol he had created based on the standard flow during AMI_Init() processing, in which the initial Tx Init() function is called first because its output IR may be passed to the first Rx, etc. - The initial Tx sees that there is no _downstream.txt. So it realizes it is the first Tx in the channel, and it creates this file and writes its own information (Tx, how many taps, etc.) into the file. - Then the Rx (the Rx of the first redriver) gets called. It reads the _downstream.txt, realizes it is the first Rx in the chain, and writes its info into the file. - The Tx of the first redriver gets called. It too reads the file, realizes it is the second Tx in the chain, and writes its info to the file. - If there is another redriver pair in the chain, it does the same. - Eventually, we get to the final Rx. It reads all the info from the _downstream.txt, and when it's done its processing it writes out a _upstream.txt file that it uses to control all the upstream devices. All of the upstream devices then read this file and react according to what commands it contains that are directed to them individually. Walter said this particular protocol assumed the terminal Rx controlled everything else. Bob Miller noted that as the chain is originally progressed, each device can essentially "count off" and figure out which device they are in the sequence. This allows the final Rx to address its commands back to the individual devices in the chain. Walter noted that he would put together a presentation explaining his example protocol. [Pin Mapping] modifications proposal: - Walter: [sharing the proposal] - Walter noted that he had first given a presentation on this topic on October 1st, 2014. - The proposal has two key changes. - 1. If a bus label is associated with more than one pin whose model name is POWER or GND, then all of these associated pins must have the same signal name. - This prevents a bus label from shorting together two different signal names. - 2. If the bus label is just the same as the signal name, you don't have to add all those POWER and GND pins to the [Pin Mapping] section at all. - The signal name can be the implicit bus label for POWER and GND pins. - This proposal has one change from what I first distributed. I had changed the character limit from 15 to 40 for bus labels (because a signal name can be up to 40 characters, and it could now be an implicit bus label with this proposal). Bob Ross objected to this, so I removed that change. - Walter: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 30 August 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives